Cooperative software application architectures are well known. In one basic implementation of a cooperative software application architecture, a currently-executing application may invoke another not-currently-executing application in what is known as a “call.” The “calling” application suspends its execution while the “called” application is executed. Once the called application terminates, execution control returns to the calling application whose execution continues from the point of suspension. The called application may be subsequently called, however the called application does not maintain execution state information from call to call. A call to an application must also specify the location within the called application from which point execution is to begin, otherwise the called application will begin execution from its first command. This is true even when the called application was called previously and where the called application terminated at a point other than the last command, as the called application does not “remember” between calls at which point it last terminated execution.
Limitations of known cooperative software application architectures may be seen with respect to Internet-based World Wide Web (“the web”) electronic commerce (“e-commerce”) applications. E-commerce applications such as Barnesandnoble.com and Amazon.com that may sell the same kind of items, in this case books, nevertheless have different interfaces for gathering similar purchase information such as customer name, address, credit card information, etc. Web based e-commerce agents such as MySimon.com and R-U-Sure.com provide prospective e-commerce shoppers with the ability to search several e-commerce web sites for a particular item in order to select the e-commerce site that maximizes their purchasing efficiency. However, such agents either direct shoppers to the e-commerce web site to make the purchase themselves
A cooperative software application architecture could be applied to bridge such e-commerce and agent applications by devising a software proxy to interact with the e-commerce site that could be called from an agent host application. In such a scenario, the host application would gather the information required by the e-commerce web site from the shopper and send it to the proxy as part of the call to the proxy. However, where the e-commerce site requires different information at different stages in a purchase transaction, execution of the proxy would need to be suspended at each stage, and control returned to the host application for additional information to be gathered from the shopper. Unfortunately, although current cooperative software application architectures can support such multi-stage transactions through the use of event-driven or callback techniques where the called application returns control to the host application to gather the required information, a subsequent call from the host application would result in the called application being executed from its first command, and not from the point of its suspension.
Another limitation inherent in known cooperative software application architectures is the inability of an interpreted calling application written in one programming language to share variables with an interpreted called application written in a different programming language. One reason for writing a cooperative software application using two different languages is that different aspects of the application might be best implemented in different languages. Although some programming languages do allow for code to include code snippets written in another language, there is no mechanism to allow the different code segments to share the same variables.